Recently, network devices that form computer networks have been adapted to enable a form of networking referred to as “software-defined networking.” In software-defined networking, the forwarding plane of a network switch, router or other network device is made available via a communication protocol such that this forwarding plane may be configured via the communication protocol rather than a routing protocol. In many implementations, the network devices may execute software to enable communications with other network devices in the network via this communication protocol so as to configure paths through the network. One example of a communication protocol that facilitates software-defined networking is the so-called “OpenFlow” communication protocol. OpenFlow is an open standard that allows users (e.g., researchers) to install software on the routers to run experimental or proprietary protocols to control packet routing or switching within a network.
The software controlled path setup may then orchestrate the configuration and deployment of paths on an as-needed basis to suit a particular service. To illustrate, orchestrating software that controls path setup may be manually configured with information identifying a network address translation (NAT) service operated by a first network device (service node). A second network device that does not provide a NAT service may communicate with the orchestrating software, learn of this NAT service and subscribe to this service, whereupon the orchestrating software may configure a path through the network from the second network device to the first network device. The second network device may then push traffic requiring NAT service through the path, where the first network device may apply the NAT traffic. When establishing the path, the orchestrating software may configure one or more filters on the second network device controlling admission of network traffic into the path. These paths having been engineered for a particular service, i.e., NAT service in this example, having filters controlling admission to the path may be referred to as “service engineered paths” (or “SEPs”). In this respect, the orchestrating software may define these SEPs to suit a particular service in terms of defining filters tailored for that service.
While SEPs may provide for service sharing and enable other network devices to forward traffic via a path that meets the needs of the service application (e.g., in terms of quality of service (QoS) provided, bandwidth, etc.), often network administrations must statically configure or otherwise specify the location of the service and various parameters associated with the service. Thus, when deploying new services within a network, the network administrator must update this database of service related information so that the orchestrating software may configure SEPs through the network directing traffic to these services. Manual entry of this data is both time consuming and prone to human error. Moreover, network administrators may not update this data as various service parameters change over time potentially resulting in inefficient utilization of the service.